[Previous] [Next] [Index] [Thread]

re: what are realistic threats

At 10:00 AM 9/28/94 -0400, Dave Kristol wrote:

>Given these definitions, an "active" attack is the same as a "hardware"
>attack.

That is *not* the widely-accepted definition, and it will just cause
confusion.

Regarding definitions, how about  these (again, from a IRTF/IETF  document
in progress):

    A *passive attack* does not modify data or affect system operation
    but an *active attack* does.

Further, in the Internet, where the hardware is usually generic and
programmable, attacking a relay and replacing or modifying its software is
much more cost effective for the attacker than replacing the hardware.
Also, the replacement can be accomplished from *anywhere in the world*.

If you need some more contextual vocabulary . . .

1.5.1  Threats

This Architecture includes mechanisms and techniques that can minimize
security vulnerabilities in Internet protocols and protect against diverse
threats.  A *threat* is a potential violation of security.  A threat exists
when there is a circumstance, capability, or event that could breach
security and cause harm.  This Architecture deals only with intentional,
intelligent threats, but a complete information security plan must also
deal with accidental kinds of threats.  Accidental threats, which range
>From natural disasters to equipment failures to human errors, are discussed
elsewhere [FIPS31].

An *intelligent threat* is a circumstance in which an adversary has the
technical and operational capability to detect and exploit a vulnerability
and also has the demonstrated, presumed, or inferred intent to do so.  The
elements of such a threat are shown in Figure 1-6.

A *vulnerability* is a flaw or weakness in a system's security.  That is, a
vulnerability is a characteristic or state of a system that could be
exploited to cause harm by disclosing, modifying, or destroying data or
resources, or by denying service to users.


             Figure 1-6.  Elements of an Intelligent Threat
------------------------------------------------------------------------

+-----------------------------+      +- - - - - -+---------------------+
|               Threat Action |      | Counter-  |  Internet  Element  |
|                  (Attack)   |      |           |       (Target)      |
| +----------+                |      | measures  | +-----------------+ |
| |  Threat  |<===========================||<======|  Vulnerability  | |
| |  Agent   |     Passive    |      |           | | +- - - - - - -+ | |
| |(Attacker)|<==========================>||<=======>|  Alteration | | |
| +----------+     Active     |      |           | | +- - - - - - -+ | |
|                             |      |           | +-----------------+ |
+-----------------------------+      +- - - - - -+---------------------+

+---------------------+
| Threat Consequences |  Disclosure, Deception, Disruption, Usurpation
+---------------------+

+---------------------+  +--------------------+  +---------------------+
| Attacks             |  | Vulnerabilities    |  | Countermeasures     |
+---------------------+  +--------------------+  +---------------------+
  Passive vs Active        in Design and           Protocol Features
  Outsider vs Insider      Development and         Element Functions
  (per a perimeter)        Operation Management    Usage Constraints

------------------------------------------------------------------------

A *threat action* is an actual assault on security.  A *threat consequence*
is a violation of security that results from a threat action.  A threat
action that results from an intelligent threat is called an *attack*.  That
is, an attack is an intentional act involving a means or method of
exploiting a vulnerability.  An intelligent *threat agent* is an
*attacker*, a malicious or hostile adversary with the motivation and means
to carry out an attack.  A *passive attack* does not modify data or affect
system operation, but an *active attack* does.  This Architecture is
concerned with both passive and active attacks.

This Architecture assumes that Internet protocols are already designed to
deal with accidents, but the mechanisms used for this do not always work
well for intentional threats.  For example, cyclic redundancy checks (CRCs)
are effective in detecting many forms of benign transmission errors, but
CRCs by themselves are not suitable for detecting malicious alteration of
transmitted data.  An attacker who modifies data protected by a CRC can
also modify the CRC value to match the modified data.  Thus, from a
security perspective, a CRC is a vulnerable form of manipulation detection
code.

A *countermeasure* is something that reduces a threat either by eliminating
or preventing it, by minimizing the harm it can cause, or by discovering
and reporting threat actions so that corrective action can be taken.  For
example, the vulnerability of a CRC can be reduced by suitable encipherment
techniques.